See JENKINS-61808.

The <f:password/> form control has a magic behavior, provided by Functions#getPasswordValue and a converter in Secret.java:
If it's backed by a Secret, it will use the encrypted form of the password (or token, key, etc.) as value, rather than the plain text.
Additionally, if it's backed by a Secret, an Item is in the URL hierarchy, and the user lacks Item/Configure, it will only receive ****** to be rendered, instead of a real value.
The latter is less important since Jenkins 2.223, which introduced read-only forms for users with Item/ExtendedRead, and a representation of f:password that doesn't even attempt to render a real value.

Unfortunately, many plugin maintainers get this wrong and use String-based for values only shown using <f:password/>. This affects both plugins who get storage right (using Secret), and those that get that part wrong, too.

So what does this do?

• When rendering an <f:password/>, even if it's not backed by a Secret, we will convert the value to be shown to a Secret and render its encrypted form in most cases.
  Additionally, we also allow non-Secret backed <f:password/> to be ****** out when the user lacks a relevant Item/Configure permission.
• When processing form submissions, a new Converter will convert any value that's an encrypted Secret to its decrypted String representation.

In addition to the above, we also add a new warning to the log whenever a <f:password/> is backed by a string, and attempt to identify which view it's coming from (which is surprisingly annoying to do). This PR does not mean that plugins having String APIs wouldn't be a bug. This warning will appear when running jetty:run and hpi:run, but not in production use. It can also serve as a useful reminder that the underlying field should be a Secret.

Since the APIs for password parameters were using the String type, they have been adapted in this PR.

Escape hatches

This PR introduce more magic, so we have two different escape hatches in case things go sideways:

• hudson.util.Secret.AUTO_ENCRYPT_PASSWORD_CONTROL is true by default and controls whether the basic new behavior is active. This must be set on startup, as we don't even want the converter to register if something goes wrong.
• hudson.util.Secret.BLANK_NONSECRET_PASSWORD_FIELDS_WITHOUT_ITEM_CONFIGURE is true by default and controls whether the ***** masking that existed for Secret backed f:password fields is extended to those without a Secret.

Limitations

This introduces a slight regression with String-based "setter" APIs around a Secret field: A round-trip will now result in changes to the persisted value, as Jenkins transparently decrypts any submitted value. IOW, it now behaves as though the user always entered the same value manually.

In development mode, Jenkins will log warnings when it encounters secrets not backed by a Secret, including fields showing a fixed String value that's not protection-worthy. This should rarely occur legitimately. It would occur on "Build With Parameters" with password parameters, which use a fixed <DEFAULT> placeholder, if we didn't specifically support that in getPasswordValue, and it happened in the "Parameters" action of builds when not showing a password value, so I replaced the (inappropriate) use of f:password there.

If the storage of credentials is wrong, rather than just the Java API exposing values to form fields, then users can still obtain the plain-text stored credential using GET config.xml. But plain-text storage of credentials is a problem independent of the UI and remote API to begin with and would need to be addressed anyway.

This PR removes a protection that would make (some) unit tests fail:

Proposed changelog entries

• Security hardening: Always round-trip password form control values in an encrypted form, even if not backed by an encrypted Secret field. In case of problems, this can be disabled by setting the system property hudson.util.Secret.AUTO_ENCRYPT_PASSWORD_CONTROL to false on startup.
• Security hardening: Always use a placeholder value for password form control values in item related configuration forms when the user is missing Item/Configure permission, even if not backed by an encrypted Secret field. In case of problems, this can be disabled by setting the system property hudson.util.Secret.BLANK_NONSECRET_PASSWORD_FIELDS_WITHOUT_ITEM_CONFIGURE to false.

Or we can limit the details we expose to users here and just go with

• Security hardening related to password form fields.

If there are real problems, we can provide the system properties in regression reports.

Proposed upgrade guidelines

N/A

Submitter checklist

• JIRA issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• [n/a] For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a JIRA issue should exist and be labeled as lts-candidate